home *** CD-ROM | disk | FTP | other *** search
/ Floppyshop 2 / Floppyshop - 2.zip / Floppyshop - 2.iso / diskmags / 0022-3.564 / dmg-0103 / info90 / 541.txt < prev   
Text File  |  1997-04-16  |  19KB  |  503 lines
  1.  
  2. INFO-ATARI16 Digest         Mon, 14 May 90       Volume 90 : Issue  541
  3.  
  4. Today's Topics:
  5.          (none) really problems with memory upgrade **FLAME**
  6.                       8086 C Cross Compiler ???
  7.                        Arcgsh: New Version 3.0
  8.                 CALL FOR VOTES: comp.sys.atari.st.tech
  9.                  changing directory with a program??
  10.                  Determining Own Name - Major BooBoo
  11.                            getting argv[0]
  12.                            MMU on Atari ST
  13.                              PRO GEM 13+
  14.                Uniterm/Tektronix 4100 terminal emulator
  15.                   wanted, 68000 filled polygon code
  16.                        WHERE IS PINHEAD????????
  17. ----------------------------------------------------------------------
  18.  
  19. Date: 14 May 90 07:22:53 GMT
  20. From: eagle.wesleyan.edu!ncastellano@CS.YALE.EDU
  21. Subject: (none) really problems with memory upgrade **FLAME**
  22. Message-ID: <23013@eagle.wesleyan.edu>
  23.  
  24. In article <398@van-bc.UUCP>, johna@van-bc.UUCP (John Altstadt) writes:
  25. >  In article <22828@eagle.wesleyan.edu> ncastellano@eagle.wesleyan.edu writes:
  26. >  >In article <9005130650.AA28761@Sunburn.Stanford.EDU>, FTJLH@ALASKA.BITNET
  27.  ("Prinz_Arcturus") writes:
  28. >  >> ZRAM video flicker
  29. >  >>    as I was saying... the left and right borders of what I see on a mono
  30. >  >> monitor jump back and forth several chars worth. The rightmost char gets
  31. >  >> wrapped around to the next line. All this on a 1040 taken to 2.5, with
  32. >  >> all the rf shields left off. The ZRAM sits right on top of the video
  33. >  >  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  34. >  >
  35. >  >  This is probably the source of the problem.
  36. >  >
  37. >  >> shifter.
  38. >  >>     Any help appreciated.... I'll try to get in there again and shield
  39. >  >> what I can.... but, right now, the jitter has stopped and I'm merely
  40. >  >
  41. >  >What do you want help with?  You've already indicated the problem and the
  42. >  >most likely solution, so what can we say?
  43. >  >
  44. >  >> right shifted several chars. Thanks for any comments.
  45. >  >>       J Harris         Fairbanks/Alaska
  46. >  >--
  47. >  >        ncastellano@eagle.wesleyan.edu    ncastellano@wesleyan.bitnet
  48. >  >                Sinkhole!dEADHEAd@mast.citadel.moundst.mn.org
  49. >  >   "We are happy.  (_silence._)  What do we do now, now that we are happy?"
  50. >  >               -Estragon, _waiting for godot_ by samuel beckett
  51. >
  52. > Wow, you read it here first on usenet:  removing the shielding (that is
  53. > wrapped around the OUTSIDE of all the circuit boards) that was designed to
  54. > reduce radio and television reception interference, will make electrical
  55. > signals take several milliseconds longer to propagate through wires.  In
  56. > fact, the wires become storage devices capable of storing several clock
  57. > pulses along their lengths.  RAM prices should drop dramatically now
  58. > that the secret is out, otherwise everybody will replace their RAMs
  59. > with loops of wire.  Anybody want to continue this thread on alt.urbane.
  60. > legends?
  61. >
  62.  
  63. WARNING: ***FLAME ON***
  64.  
  65. Electronic propagation delays are not the only source of monitor
  66. flickering.  Pardon me for living, but it sounded to me like a safe
  67. assumption that removing the RF shield could cause RF leakage which
  68. could interfere with a monitor.  So I suggested that he try to put it
  69. back on.  Is that any reason for you to be snide and flame me?  The
  70. purpose of this newsgroup is to provide information, not to prove who
  71. is the biggest hotshot know-it-all who can make everyone else look
  72. stupid.  Well, my friend, the only one who looks stupid here is you.
  73. Read on...
  74.  
  75. > What sort of a school is this "wesleyan" anyways?  Judging by the
  76. > ..signature it must be either philosophy or theatre.  It's certainly
  77. > "creative".
  78. >
  79.  
  80. What the HELL does my school have to do with anything?  Yes, they
  81. teach philosophy here, and yes, we have quite a large theatre
  82. department.  We also have a math department and a physics department.
  83. Are students at liberal arts institutions not allowed to post on
  84. matters of a technical nature?  Sorry, I must have missed the sign on
  85. the door that said "Only engineering students allowed."  My signature
  86. is there because I like it, it has nothing to do with my school, my
  87. major, or what my interests besides literature are.  I am a COMPUTER
  88. SCIENCE major.  Should I have put some really brilliant quote from
  89. Niklaus Wirth in my .signature?  The only thing that makes someone
  90. more qualified than me to post on a subject is if they know more about
  91. it than I do, which has nothing to do with my school, my .sig, or
  92. whether or not you think you're god's gift to the world of
  93. electronics.  Grow up.
  94.  
  95. > From my own experience with memory upgrades, I would say that the problem
  96. > is that there are two different physical banks of RAM being accessed as
  97. > the same logical bank.  I upgraded my 520 to a 1040 a long time ago.
  98. > When the price of 1M chips dropped low enough last year, I popped in
  99. > a set and had results much the same as those described above.  The
  100. > problems went away when I removed the 256K DRAMs that were part of
  101. > the initial upgrade.
  102.  
  103. Gee, look at that...actual information.  Why couldn't you have just
  104. posted that without being a total asshole about my message?
  105. >
  106. > My upper RF shield was recyled long ago (it's probably part of a Buick
  107. > now) because the RAM + shield wouldn't let me put the keyboard back in.
  108. >
  109. > Cheers
  110. > John
  111. > --
  112. > John Altstadt, 6135 Carson St., Burnaby B.C., CANADA, V5J 2Z8
  113. > ...!ubc-cs!van-bc!johna || ..!uunet!van-bc!johna || johna@wimsey.bc.ca
  114. > There may, or there may not have been some :-)s up there.  There should
  115. > probably have been a few more for the humorless, lost souls out there.
  116.  
  117. There were none.  And for those who think your sense of humor sucks,
  118. it wouldn't have done a damn bit of good.  Get a clue.
  119.  
  120. *** FLAME OFF ***
  121.  
  122. --
  123.         ncastellano@eagle.wesleyan.edu    ncastellano@wesleyan.bitnet
  124.                 Sinkhole!dEADHEAd@mast.citadel.moundst.mn.org
  125.    "We are happy.  (_silence._)  What do we do now, now that we are happy?"
  126.                -Estragon, _waiting for godot_ by samuel beckett
  127.  
  128. ------------------------------
  129.  
  130. Date: 14 May 90 12:37:40 GMT
  131. From: maytag!mks.com!ant@iuvax.cs.indiana.edu  (Anthony Howe)
  132. Subject: 8086 C Cross Compiler ???
  133. Message-ID: <1990May14.123740.5288@mks.com>
  134.  
  135. I was wondering if there was a cross-compiler that produced 8086 code or
  136. maybe a 68000->8086 translating assembler. I'm hoping that such a beast
  137. might exist which would solve my need to get any expensive PC emulators.
  138.  
  139. - ant
  140.  
  141. --
  142.             __                             "A thousan li journey begins
  143.  _  . .-|- / _\ .  . |_  _.    _  _  .  .   with just one step."
  144. (_\ |\| |  |(_/ |\/| |\ _\  o (_ (_) |\/|
  145.  
  146. ------------------------------
  147.  
  148. Date: 14 May 90 07:20:31 GMT
  149. From: mcsun!unido!laura!heike!klute@uunet.uu.net  (Rainer Klute)
  150. Subject: Arcgsh: New Version 3.0
  151. Message-ID: <2157@laura.UUCP>
  152.  
  153. I would like to announce version 3.0 of Arcgsh.
  154.  
  155. Arcgsh is a GEM based shell for the popular archivers Zoo, Arc, and
  156. LHarc. Besides that you can call the not-so-popular-anymore Shar. A GEM
  157. interface to Uud and Uue eases decoding of articles you grabbed from the
  158. net resp. encoding files for distribution via net or e-mail.
  159.  
  160. Main improvements over Arcgsh V2.1c:
  161. - Support of Arc V6.02.
  162. - Support of LHarc V1.13 (posted in comp.binaries.atari.st some weeks
  163. ago). I am not quite happy with LHarc because there are several formats
  164. of LHarc archive files floating around and still no English
  165. documentation is available. Consequently you might not be able to
  166. extract every .LZH file but only those LHarc V1.13 can decode. (For
  167. other .LZH files Unlzh may be helpful.) Due to the lack of documentation
  168. the Arcgsh GEM interface relies on some guesses I made and some options
  169. are not (directly) available. Hopefully the situation will get stable some day.
  170.  
  171. I am still working on the Arcgsh documentation which will be more
  172. detailed than the former one. It will be distributed in LaTex format.
  173. For those poor souls without TeX an ugly looking ASCII version will be
  174. included.
  175.  
  176. Arcgsh V3.0 will appear in comp.binaries.atari.st within the next few weeks.
  177.  
  178.   Dipl.-Inform. Rainer Klute      klute@heike.informatik.uni-dortmund.de
  179.   Univ. Dortmund, IRB             klute@unido.uucp, klute@unido.bitnet
  180.   Postfach 500500         |)|/    ...uunet!mcvax!unido!klute
  181. D-4600 Dortmund 50        |\|\    Tel.: +49 231 755-4663
  182.  
  183. ------------------------------
  184.  
  185. Date: 14 May 90 01:21:18 GMT
  186. From:
  187.  usc!zaphod.mps.ohio-state.edu!uwm.edu!bionet!turbo.bio.net!wam.umd.edu@ucsd.edu
  188.   (David M. Baggett)
  189. Subject: CALL FOR VOTES: comp.sys.atari.st.tech
  190. Message-ID: <1990May7.024120.19065@wam.umd.edu>
  191.  
  192. [I did not receive a call for discussion for this group.-eliot]
  193.  
  194. *** PLEASE READ THIS ENTIRE MESSAGE BEFORE REPLYING ***
  195.  
  196. This is the first call for votes for creation of a new group
  197.  
  198.         comp.sys.atari.st.tech
  199.  
  200. The voting period will last until 11:59 PM on June 4, 1990.
  201.  
  202. *** DON'T VOTE UNTIL YOU READ THE WHOLE MESSAGE! ***
  203.  
  204. The charter of the group, if created, will be as follows:
  205.  
  206. Charter for comp.sys.atari.st.tech
  207. ----------------------------------
  208.  
  209.    comp.sys.atari.st.tech is devoted to technical discussion
  210. regarding Atari ST software and hardware.  Examples of topics to
  211. be discussed in this newsgroup include:
  212.  
  213.    "What are the pinouts for the ___ port on the ST?"
  214.  
  215.    "Has anyone managed to hook up a ___ successfully?"
  216.    (Assuming this is a nontrivial task)
  217.  
  218.    "Which system vector controls ____?"
  219.  
  220.    "What is the official, Atari-sanctioned method of doing ___?"
  221.  
  222.    "What are the specs for ___ file format?"
  223.  
  224.    "How does ___ manage to get 20 million colors on the screen?"
  225.  
  226.    "What is the best way to do fine scrolling?"
  227.  
  228.  
  229. Examples of topics NOT to be discussed in this newsgroup include:
  230.  
  231.  
  232.    "How do you get past the dragon in ___ game?"
  233.  
  234.    "For sale: ___"
  235.  
  236.    "New product announcement: ___"
  237.  
  238.    "My ST is better than your ___ because"
  239.  
  240.    "My ___ is better than your ST because..."
  241.  
  242.    "Atari's financial situation is ___"
  243.  
  244. -----------------------------------------------------------------------------
  245.  
  246. comp.sys.atari.st.tech, if created, will be unmoderated.
  247.  
  248.  
  249. HOW TO VOTE
  250. -----------
  251.  
  252. To cast a vote, send a mail message to dmb@wam.umd.edu with either of
  253. the following subject lines:
  254.  
  255.         Subject: Vote YES for comp.sys.atari.st.tech
  256.         Subject: Vote NO  for comp.sys.atari.st.tech
  257.  
  258. THE BODY OF THE MESSAGE WILL BE IGNORED.  Nothing placed in the body will
  259. be used in counting votes.
  260.  
  261. No vote with an incorrect subject line will be counted!
  262.  
  263. ONLY votes MAILED to dmb@wam.umd.edu will count. Votes posted to the net
  264. for any reason (including inability to get mail to dmb@wam.umd.edu) and
  265. proxy votes (such as having a mailing list maintainer claim a vote for
  266. each member of the list) will not be counted.
  267.  
  268. Voting deadline:  11:59PM June 4, 1990
  269.  
  270. Dave Baggett
  271. dmb@wam.umd.edu
  272.  
  273. ------------------------------
  274.  
  275. Date: 14 May 90 09:43:34 GMT
  276. From: usc!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!tut!tukki!suhonen@ucsd.edu
  277.  (Timo Suhonen)
  278. Subject: changing directory with a program??
  279. Message-ID: <4528@tukki.jyu.fi>
  280.  
  281. Hi!
  282.  
  283. Is there a way to change directory with a program so that the change
  284. can be seen after the program in desktop (or in a shell; I use gulam)???
  285.  
  286. I'm writing a program that changes directory with a TOS call (migh be
  287. 3F; can't remember). The call returns a 0 (success), but when the program
  288. exits I am again in the same directory where I started the program. This
  289. happens both with gulam shell or with desktop.
  290.  
  291. I have good old 520ST with 1M RAM and TOS dated 85 (or 86) and I use
  292. Sozobon C version 1.1(?).
  293.  
  294. Timo
  295. --
  296. Timo Suhonen                                           suhonen@tukki.jyu.fi
  297.                   I am logged in, therefore I am
  298.  
  299. ------------------------------
  300.  
  301. Date: 14 May 90 10:58:31 GMT
  302. From: mcsun!hp4nl!phigate!ehviea!leo@uunet.uu.net  (Leo de Wit)
  303. Subject: Determining Own Name - Major BooBoo
  304. Message-ID: <784@ehviea.ine.philips.nl>
  305.  
  306. In article <888@ncs.dnd.ca> balkwill@ncs.dnd.ca (R. J. Balkwill) writes:
  307.     []
  308. |A general solution to the problem that doesn't break any rules or make
  309. |assumptions about future TOS's is unknown to me.  True, that if one
  310. |has a shell that uses ARGV and if one's compiler inserts
  311. |ARGV-compatible startup code, all is fine.  Not all shells and
  312. |compilers cooperate.
  313. |
  314. |Dlibs uses a method (with uncooperative shells) based on accessing the
  315. |stack of the parent process (assuming there is one) to see what name
  316. |it supplied to the Pexec().  It works but it looks kind of fragile
  317. |unless Atari has sworn not to alter the key components.
  318.  
  319. This does not work with Pexec(4,...), since that call doesn't even
  320. _use_ a program name. It seems to prevent any fundamental solution to
  321. the problem (other than to fix GEMDOS, but that is a fundamental one).
  322.  
  323. |
  324. |There does appear to be a reserved slot in the basepage at offset 40.
  325. |Perhaps this was originally intended to point to prog name.  It would
  326. |have been nice.
  327. |
  328. |P.S.  I tested my 'procedure' and got a nice virgin-looking dta - all
  329. |zeros.
  330.  
  331. Of course; the initial dta starts at the same address as your program's
  332. argument string! That's why your assumption about the dta was wrong in
  333. the first place (Fgetdta() gives the process' own disk transfer address
  334. - initialized by GEMDOS to point to the same address as the program's
  335. argument string -, not that of the parent).
  336.  
  337. |
  338. |Bob (iq--)
  339.       ~~~~ braindamage? 8-)
  340.  
  341.     Leo.
  342.  
  343. ------------------------------
  344.  
  345. Date: 14 May 90 08:34:57 GMT
  346. From: hpcc01!hpbbn!hpbbi4!stefan@hplabs.hp.com  (#Stefan Bachert)
  347. Subject: getting argv[0]
  348. Message-ID: <510006@hpbbi4.HP.COM>
  349.  
  350. / hpbbi4:comp.sys.atari.st / silvert@cs.dal.ca (Bill Silvert) /  3:16 pm  May
  351.  12, 1990 /
  352. > Huh?  How do things like FOLDRXXX.PRG get their name then?
  353.  
  354. What is about reading the directory for foldr*.prg ?
  355.  
  356. Stefan
  357.  
  358. ------------------------------
  359.  
  360. Date: 14 May 90 08:17:40 GMT
  361. From: hpcc01!hpbbn!hpbbi4!stefan@hplabs.hp.com  (#Stefan Bachert)
  362. Subject: MMU on Atari ST
  363. Message-ID: <510005@hpbbi4.HP.COM>
  364.  
  365. / hpbbi4:comp.sys.atari.st / rcb@netcom.uucp (Roy Bixler) /  4:15 am  May 11,
  366.  1990 /
  367.  
  368. > I'm wondering if there are any possibilities of replacing the MMU on the
  369. > ST with one that gives memory protection.  I'd like to upgrade to Unix
  370. > and not have to buy an expensive new machine.  I realize there are
  371. > people out there interested in this idea, so has anyone had any luck?
  372. >
  373. > Roy Bixler
  374. > rcb@netcom.uucp
  375. > ----------
  376.  
  377. There is an other pit fall. The 68000 is not able to continue
  378. an aborted bus cycle. So you cannot implement demand paging
  379. easily. If you omit demand paging you need a lot of memory.
  380. And for UNIX 4 MB is really less.
  381.  
  382. So you have to wait for the day ATARI will offer the TT under UNIX.
  383. (hopefully this day will come and hopefully ATARI will support UNIX unlike
  384. GEM/TOS)
  385.  
  386. By the way what is about MINIX on ST?
  387.  
  388. Stefan
  389.  
  390. ------------------------------
  391.  
  392. Date: Mon, 14 May 90 13:45:40
  393. From: "Simon Chappell"
  394.  <S61304%PRIME-A.POLY-SOUTH-WEST.AC.UK@CORNELLC.cit.cornell.edu>
  395. Subject: PRO GEM 13+
  396.  
  397. Does anyone know how to get hold of the PRO GEM articles after number
  398. thirteen? I have the first thirteen but I have heard that there are
  399. others! I have no FTP access outside of the UK, so if you have these
  400. articles could you mail me them, using either UUE or ordinary text
  401. (No binary mailings please!)
  402.  
  403. Regards,
  404.  
  405. Simon
  406.  
  407.  
  408. | Simon Chappell,  B.Sc(Hons) Computing and Informatics (Final Year)
  409. | 51 Amherst Road, Penny-Come-Quick, Plymouth, Devon, PL3 4HJ, UK.
  410. | JANET: s61304@uk.ac.psw.pa   (Until the end of June 1990)
  411. |
  412. | Holder of the ST Penpals list. Join now and beat the Christmas rush!!
  413. |
  414. | "The box said nothing, only this time louder!" - Terry Pratchett
  415.  
  416. ------------------------------
  417.  
  418. Date: 12 May 90 17:17:52 GMT
  419. From:
  420.  zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!smurf!gopnbg!tmpmbx!e
  421.  inoed!utopia!neon!woju@tut.cis.ohio-state.edu  (Wolfgang Jung)
  422. Subject: Uniterm/Tektronix 4100 terminal emulator
  423. Message-ID: <1087@neon.UUCP>
  424.  
  425. ashwin@gatech.edu (Ashwin Ram) writes:
  426.  
  427. >Hi... I'm a long-time user of UNITERM but I've been a little behind on
  428. >upgrades.  What is the latest version available?
  429.  
  430. So far i think the latest version is UNITERM V20E 011
  431. If' there is a newer Version off Uniterm, it would be nice, if
  432. the one post it to the binaries...
  433.  
  434.  
  435. CU
  436.  
  437. --
  438. ===================================================================
  439. #  Wolfgang Jung                      Email:woju@neon.UUCP        #
  440. #  Germany                                                        #
  441. ===================================================================
  442.  
  443. ------------------------------
  444.  
  445. Date: 14 May 90 19:01:41 GMT
  446. From: usc!samsung!munnari.oz.au!murtoa.cs.mu.oz.au!viccol!gjocc@ucsd.edu
  447. Subject: wanted, 68000 filled polygon code
  448. Message-ID: <6203.264eba46@csv.viccol.edu.au>
  449.  
  450.   I am currently writing a game in compiled STOS BASIC (yuck why
  451.   didn't they write STOS 'C' or STOS Pascal?).
  452.  
  453.   I find that the STOS polygon instruction is too slow for
  454.   my needs (It probably just uses LINE A?).
  455.  
  456.   Does anyone out there have a fast 68000 assembler routine for
  457.   drawing filled polygons?
  458.  
  459.   I dont even need a general routine, just low res, solid fill, four vertices,
  460.   and blinding speed.
  461.  
  462.   Help, I haven't written any 68000 assembler before.
  463.   (although I did write some Z-80 assembly code years ago :-).)
  464.  
  465.  
  466. Greg O'Sullivan (gjocc@csv.viccol.edu.au)
  467.  
  468. ------------------------------
  469.  
  470. Date: 14 May 90 13:55:59 GMT
  471. From:
  472.  usc!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!watserv1!watcgl!electro!ig
  473.  nac@ucsd.edu  (Ignac Kolenko)
  474. Subject: WHERE IS PINHEAD????????
  475. Message-ID: <1786@electro.UUCP>
  476.  
  477. In article <9005092019.AA06214@Argus.Stanford.EDU> SA44@liverpool.ac.UK (Kevin
  478.  Maguire) writes:
  479. >It seems that GEMDOS doesn't clear the memory if a program has no
  480. >relocation data (last word in GEMDOS header == FFFF)
  481.  
  482. this is because in writing a $FFFF into the last word of the header, you
  483. are toggling the TOS 1.4 fast file load bit, which ends up doing
  484. EXACTLY the same thing like PINHEAD, but with less problems since this is
  485. an actual feature of TOS 1.4, rather than a patch program like pinhead.
  486. (correct me if i'm wrong - with a 1040, you can't really notice any
  487. difference, although people with 520's claim that pinhead speeds things
  488. up enormously - more a placebo effect than anything else i think!)
  489.  
  490.  
  491.  
  492.  
  493. --
  494. =====Ignac A. Kolenko (The Ig)=====watmath!watcgl!electro!brasoft!ignac======
  495.      co-author of QuickST, and the entire line of Quick Software!!!!
  496.   Branch Always Software Box 2624, Station B, Kitchener, Ont. CANADA N2H 6N2
  497. =============================================================================
  498.  
  499. ------------------------------
  500.  
  501. End of INFO-ATARI16 Digest V90 Issue #541
  502. *****************************************
  503.